本期精读的文章是：V8 引擎特性带来的的 JS 性能变化
定时刷新一下对 js 的三观，防止经验变成坑。（对 IE 等浏览器的三观需保持不变）
try catch 非常有用，特别在 node 端更是一个常规操作。前端框架也越来越多采用了异常捕获的方式，结合 async await 让代码组织得更加优雅，详细可以看我的这篇博文 统一异常捕获。react mixins 也喜欢 try 住 render 方法，包括 16 版本自动 try 住了所有 render，try catch 可谓无处不在。
node 8 版本之后 try 内部函数性能损耗可以忽略不计。
但是当前版本仍然存在安全隐患，将 这里的代码 拷贝到 chrome 控制台，当前页面会进入无限死循环。
此例子对 try catch 块做了大量循环，官方说法是在某些代码组合情况下陷入无限优化循环。
js 正在变得越来越简单，该 delete 的地方也不会犹豫是否写成 undefined，以提升性能为代价降低代码可读性了。
在 node8.3 版本及以上，该使用拓展运算符获取参数，不但没有性能问题，可读性也大大提高，结合 ts 时也能得到类型支持。
但是在 react 中副作用仍需警惕。由于 ui 组件复用次数在大部分场景及其有限，强烈推荐使用箭头函数书写成员函数（在我的另一篇精读 This 带来的困惑 有详细介绍），而且在 node8 中，箭头函数的性能是最好的。
对函数调用优化的越来越好，不需要过于担心注释与空白、函数间调用对性能的影响.
node8 对超长数字计算性能还是较低，大概是 32 位数字性能的 2/3，所以尽量用字符串处理大数。
基本用法有 for in Object.keys Object.values. 在 node8 中，for in 将变得更慢，但任然比其他两种方法快，所以，尽早取消不必要的优化。
创建对象速度在 node8 得到极大提升，似乎是面向对象编程的福音。
当函数或者对象存在多种类型参数时，在 node8 中性能没什么优化，但单态函数性能大幅提升。所以尽量让对象内部属性单态是比较有用的，比如尽量不要对字符串数组 push 一个数字。
在 v8 优化之前，前端 try catch 存在挺大的性能问题，导致许多老旧的项目很少有使用异常的场景，而经验丰富的程序员也会极力避免使用 try catch，在必须使用 try catch 的地方，将代码逻辑封装在函数中，try 住函数而不是代码块，以降低性能损失。
现在是推翻这些经验的时候了，合理的异常处理还能够优化用户体验。
前端代码最容易出错的逻辑在于对后端数据的处理，一旦后端数据出错，前端整条数据处理链路难免报错或者抛出异常。这种场景最适合将异常 try 住，显示提示文案，同时也避免代码内部对数据格式过多的兼容处理。
由于语句数量对性能影响已经忽略不计了，以前推崇的写法可以说再见了：
// 提倡
var i = 1;
var j = "hello";
var arr = [1,2,3];
var now = new Date();
// 避免
var i = 1,
j = "hello",
arr = [1,2,3],
now = new Date();这波 v8 优化带来了一些 js 性能上的改变，但在 js 性能优化中只解决了很小一块问题，而 js 在前端性能优化又只是冰山一角，dom 与 样式 的优化对性能影响也非常重大，我们仍然应该重视代码质量，提高代码性能。
如果你想参与讨论，请点击这里，每周都有新的主题，每周五发布。